home *** CD-ROM | disk | FTP | other *** search
/ Amiga Format CD 22 / Amiga Format AFCD22 (Jan 1998, Issue 106).iso / -in_the_mag- / picmanagerpro / docs / important.doc next >
Text File  |  1997-11-19  |  6KB  |  157 lines
  1.  
  2.  Some important notes on specific crashes and crashing conditions
  3.  ================================================================
  4.  
  5.  Hard/Software Conflicts
  6.  ~~~~~~~~~~~~~~~~~~~~~~~
  7.  
  8.  IDE-MaxTransfer Problem
  9.  -----------------------
  10.  Since superview.library usually holds very large buffers within
  11.  memory, it also likes to read and write these completely from and to
  12.  disk. This means, that the specific device drivers are confronted with
  13.  quite large values of bytes to be read or written, which perhaps
  14.  usually does not happen very often.
  15.  
  16.  Sometimes the firmware of IDE-Harddrives, like used with the
  17.  A4000/030-040 or A1200HD, does not support transfers of blocks
  18.  larger than 64K (65535 Bytes) during one single write operation.
  19.  Ususally the DOS splits larger writing calls to take care of this
  20.  restriction. But since this is just a lack of performance and actually
  21.  does not comply to the IDE/AT standard, the default value for
  22.  this "MaxTransfer" is not 0xFFFF (64K) but 0xFFFFFF or 0xFFFFFFFF instead.
  23.  
  24.  If any written graphics files are mysteriously damaged or will be
  25.  read incorrectly (writing is more critical than reading), you should
  26.  start your "HDToolBox" and select "Partition Drive" for the concerned
  27.  HardDrive. After that activate "Advanced Options" and chose "Change".
  28.  Modify the "MaxTransfer" field, so that it does reflect "0xFFFF" then.
  29.  After that leave all the windows by confirming "OK" and select
  30.  "Save Changes to Drive" (no longer disabled) on the first window.
  31.  
  32.  >>> Do not change any other settings within "Partition Drive", if
  33.      you don't know, what you're doing, since actually partitioning
  34.      your HardDisk would cause your complete data to be lost.
  35.      If you'd changed something you didn't want to change, just
  36.      "Cancel" and start from the beginning <<<
  37.  
  38.  Perhaps you'd like to know, why I did mention this here ?!
  39.  Well, some weeks after I bought a new M*xt*r 540 MB HD,
  40.  superview.library did seem to have x-time more bugs than before, which
  41.  almost all could not be explained rationally: writing a "clean"
  42.  buffer to disk in several file formats (did not matter), with this
  43.  buffer still beeing valid after the write operation, resulted in
  44.  damaged graphics after loading. If uncompressed, the data still was
  45.  all there, but like a kind of mosaic, with always some blocks at the
  46.  wrong places...
  47.  It took me some weeks to actually realize the bug itself and
  48.  approximately two days to find out, *why* it happened... %-(
  49.  
  50.  
  51.  Crashes caused by other Programs
  52.  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  53.  Here's an alphabetical list of programs, which either cause
  54.  superview.library to crash, or which do crash relatively
  55.  often and unexpected (so that it might seem, as if superview.library
  56.  crashed):
  57.  
  58.     - AutoCLI V2.xx © by Nic Wilson
  59.  
  60.       Problem:
  61.       AutoCLI sometimes might crash, when there's no appropriate
  62.       window available when e.g. trying to open a shell via Hotkey.
  63.  
  64.       Solution:
  65.       (don't use the hotkey feature)
  66.  
  67.     - EGS libraries V6.x/7.x © VIONA Development
  68.  
  69.       Problem:
  70.       When flushing the EGS libraries (at least after using the Amiga
  71.       emulation mode), it seems that the libraries will cause recoverable
  72.       alerts with OS 3.x. Maybe on some systems crashes will occur.
  73.       Don't know, whether the libraries are really the source,
  74.       but it's likely.
  75.  
  76.       Solution:
  77.       (don't flush)
  78.  
  79.     - NewMode V3.3 (and below) © 1992-95 by Andreas Linnemann
  80.  
  81.       Problem:
  82.       Has been reported to cause serious problems when running together
  83.       with e.g. SuperView (when attaching a fixed ViewMode to the program).
  84.  
  85.       Solution:
  86.       (Already fixed for newer versions.)
  87.  
  88.     - SnoopDos 3.00 © Eddy Carrol, September 1994
  89.  
  90.       Problem:
  91.       When monitoring OpenLibrary() calls with SnoopDos 3.0,
  92.       while loading the libraries into RAM, ramlib will _sure_
  93.       crash with an "...3 odd address" guru when loading one of
  94.       the SVObjects.
  95.       This does not happen when the libraries have already been
  96.       loaded into RAM before and does also not happen with older
  97.       SnoopDos releases.
  98.       Can't say, whether this is a problem of SnoopDos, ramlib
  99.       or the library, but maybe it has s.th. to do with trashed A0/A1,
  100.       pointers badly corrupted under different circumstances.
  101.  
  102.       Solution:
  103.       Deactivate "OpenLibrary" under "Functions" and save the preferences.
  104.       You will still be able to see, which libraries are loaded (LoadSeg),
  105.       but can't detect any version numbers (use an older SnoopDos for this).
  106.  
  107.     - SuperDark 1.5c,V2.1a © by Thomas Landspurg
  108.  
  109.       Problem:
  110.       Some of the Screen Blanker modules will crash on AGA OS3.x systems.
  111.  
  112.       Solution:
  113.       Find out, which of them do so (e.g. ASwarm, as far as I know) and
  114.       deactivate them !
  115.  
  116.     - VMM
  117.  
  118.       Problem:
  119.       Someone told me, that VMM caused SuperView(-Library) crashing
  120.       because of Enforcer Hits, which did not happen without it.
  121.  
  122.       Well, consider this facts:
  123.  
  124.       superview.library usually does allocate all memory with the
  125.       MEMF_PUBLIC flag set. This memory will not be "virtualized"
  126.       by VMM because there's a common agreement - not respected by
  127.       many programs - that this is memory which has to been RAM always.
  128.       This default behaviour may be overriden by setting special
  129.       settings within VMM, e.g. setting 10240 for both - MEMF_PUBLIC
  130.       as well set or cleared - within "advanced options".
  131.  
  132.       By doing so, VMM might be caused to not only virtualize large
  133.       graphics buffers, but maybe also Messages, IORequests and
  134.       other things. This simply may cause crashes.
  135.  
  136.  
  137.       Solution:
  138.       (If it does not work, don't use it with SuperView - I've been
  139.        told that the above method works without problems, but you
  140.        try it at your own risk - maybe the library's behaviour will
  141.        change in the future. Either better using the MEMF_PUBLIC flag
  142.        or crashing by beeing badly virtualized ;-(
  143.  
  144.  
  145.  Conditional Configuration Crashes (CCC ;-)
  146.  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  147.  Some very special configurations (which occur when people do configure
  148.  their programs wrong, or installation programs do weird things) may
  149.  cause the whole system to crash.
  150.  
  151.  
  152.  
  153.  
  154.  If you know more about such crashing conditions, please report it to me.
  155.  
  156.  - Andy, 9.9.95
  157.